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Evolution  in  DRE  Systems 


The  Past 


Standalone  real-tinne  & 
ennbedded  systenns 

•  Stringent  quality  of  service 
(QoS)  demands 

•  e.g.,  latency,  jitter, 
footprint 

•  Resource  constrained 


The  Present 


Distributed  real-tinne  &  embedded  (DRE) 
systenns 

•  Net- centric  systenns- of- systems 

•  Stringent  simultaneous  QoS  demands 

•  e.g.,  dependability,  security,  scalability,  etc. 

•  More  fluid  environments  &  requirements 


This  talk  focuses  on  technologies  &  methods  for 
enhancing  DRE  system  QoS,  producibility,  &  quality 
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Evolution  of  DRE  Systems  Development 


Cyclic 

Exec 


Technology  Problems 

•  Legacy  DRE  systems  are 
often: 

•  Stovepiped 

•  Proprietary 

•  Brittle  &  non-adaptive 

•  Expensive 

•  Vulnerable 


Mission-critical  DRE  systems  have 
historically  been  built  directly 
atop  hardware,  which  is 

•  Tedious 

•  Error- prone 

•  Costly  over  lifecycles 


Consequence:  Small 
changes  to  legacy 
software  often  have 
big  (negative) 
Impact  on  DRE 
system  QoS  & 
produdblllty 


V 


Evolution  of  DRE  Systems  Development 


What  we  need  are  the  means  to 

•  Enhance  integrated  DRE  system  capability 
at  lower  cost  over  the  lifecycle  &  across  the 
enterprise 

•  Reduce  cycle  time  of  developing  &  inserting 
new  technologies  into  DRE  systems 
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[ml  _ What's  So  Hard  About  DRE  Software? 


Human  Nature 
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•  Organizational  impediments 

•  Economic  impediments 

•  Administrative  impediments 

•  Political  impediments 

•  Psychological  impediments 


Technical  Complexities 


Accidental  Complexities 

•  Low- level  APIs  &  debug  tools 

•  Algorithmic  decomposition 

I  nherent  Complexities 

•  Quality  attributes 

•  Causal  ordering 

•  Scheduling  &  synchronization 

•  Deadlock  avoidance 


www.dre.vanderbilt.edu/— schmidt/ reuse- lessons.html 


IQB 


Systematic  Reuse  Capabilities  for  DRE  Systems 
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UH1  DRE  System  Case  Study:  Boeing  Bold  Stroke 
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Nav  Sensors 


Expendable 

Management 


Vehicle 

Mgmt 


^  Mission  ^ 
Computer 


Bold  Stroke 
Architecture 


Systematic  reuse  platform  for 
Boeing  avionics  mission  computing 


Bold  Stroke  defined 

•  reference  standards 

•  software  interfaces 

•  data  formats 
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Mission  Computing  Services 


Middleware  I  nfrastructure 


Operating  System 


Networking  I  nterfaces 

I  y  I 


Hardware  (CPU,  Memory,  I/O) 


splc.net/fame/boeinq.html 


protocols 
system  services  & 
reusable  components 

that  enabled  distributed 
computing  &  allowed 
distributed  applications  to 
coordinate,  communicate, 
execute  tasks,  &  respond  to 
events  in  an  integrated  & 
dependable  manner 


UH1  DRE  System  Case  Study:  Boeing  Bold  Stroke 
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Systematic  reuse  platform  for 
Boeing  avionics  mission  computing 
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Mission  Computing  Services 


Middleware  I  nfrastructure 


Operating  System 


Networking  I  nterfaces 

I  y  I 


DRE  system  with  100+  developers,  3,000+  software 
components,  3-5  million  lines  of  C++/C/Ada/J  ava 

Based  on  COTS  hardware,  networks,  operating 
systems,  languages,  &  middleware 


Used  as  an  Open 
Experi  mentation 
platform  (OEP)  for 
DARPA  PCES,  MoBI  ES, 
SEC,  NEST,  &  MICA 
programs 


Hardware  (CPU,  Memory,  I/O) 


splc.net/fame/boeinq.html 
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Applying  COTS  to  Bold  Stroke 


CLIENT 


m  args 

O - — ► 

operationO 


SERVER 
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out  args  +  return 
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STUBS 


IDL 

SKELETONS 


_ IREAI^TIME 

(portable  object  ADAPTEI^ 


Networking  I  nterfaces 
Hardware  (CPU,  Memory,  l/0)j 


COTS  &  standards- based  middleware, 
language,  OS,  network,  &  hardware 
platforms 

•  Real-time  CORBA  (TAO)  middleware 

•  ADAPTIVE  Communication  Environment 
(ACE) 

•  C-i— h,  C,  Ada,  &  Real-time  J  ava 

•  VxWorks  operating  system 

•  VME,  1553,  &  Linkie 

•  PowerPC 


www.dre.vanderbilt.edu/ACE 

www.dre.vanderbilt.edu/TAO 
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Benefits  of  Using  COTS 


/  / 
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Networking  I  nterfaces 
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Hardware  (CPU,  Memory,  I/O) 


Save  a  consicderable  amount  of 
tinne/ effort  comparetd  with  tracditional 
approach  to  hancdcrafting  capabilities 

Leverage  intdustry  “best  practices"  & 
patterns  in  pre-packaged  (&  ideally) 
standardized  form 


The  use  of  COTS  is 
essentially  "outsourcing,' 
with  many  of  the 
associated  pros  &  cons 
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Limitations  of  Using  COTS 


•  QoS  of  COTS  components  is  not  always 
suitable  for  mission-critical  DRE  systems 


•  COTS  technologies  address  some,  but  by  no 
means  all,  domain-specific  challenges 
associated  with  developing  mission-critical 
DRE  systems 


{Hardware  (CPU,  Memory, 


Mission  Computing  Services 


Middleware  I  nfrastructure 

I  /I  - 

Operating  System 
Networking  I  nterfaces 


What  was  needed  was  a 
systematic  reuse  technology 
for  organizing  &  automating 
key  roles  &  responsibilities 
in  an  application  domain 
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m  Motivation  for  Software  Product- lines  (SPLs) 
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Legacy  avionics  nnission  connputing 
systems  are: 

•  Stovepiped 

•  Proprietary 

•  Brittle  &  non-adaptive 

•  Expensive 

•  Vulnerable 


Consequences: 

•  Small  changes  to 
requirements  & 
environments  can 
break  nearly  anything 

•  Lack  of  any  resource 
can  break  nearly 
everything 
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m  Motivation  for  Software  Product- lines  (SPLs) 
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Host  I  nfrastructure  Middleware 
OS  &  Network  Protocols 
Hardware  (CPU,  Memory,  I/O) 


Software 
Produce- Line 


•  SPLs  factor  out  general-purpose  &  donnain- 
specific  services  from  traditional  application 
responsibility  in  DRE  systems 

•  Manage  software  variation  while  reusing 
large  amounts  of  code  that  implement 
common  features  within  a  particular  domain 


SPLs  offer  many  opportunities  to 
configure  product  variants 

•  e.g.,  component  distribution  & 
deployment,  user  interfaces  & 
operating  systems,  algorithms  & 
data  structures,  etc. 
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Overview  of  Software  Product- lines  (SPLs) 


•  SPL  characteristics  are  captured 
via  Scope,  Commonalities,  & 
Variabilities  (SCV)  analysis 

•  This  process  can  be  applied  to 
identify  commonalities  & 
variabilities  in  a  domain  to 
guide  development  of  a  SPL 


•  Applying  SCV  to  Bold  Stroke 

•  Scope  defines  the  domain  &  context  of  the 
SPL 

•  e.g..  Bold  Stroke  component  architecture, 
object-oriented  application  frameworks,  & 
associated  components  (GPS,  Airframe,  & 
Display) 


Reusable  Architecture 
Framework 
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Hm  Applying  SCV  to  the  Bold  Stroke  SPL 


Commonalities 6escr\be  the  attributes  that  are  comimon  across  all  members  of  the 
SPL  family 

•  Common  object-oriented  frameworks  &  set  of  component  types 
•  e.g.,  GPS,  Airframe,  Navigation,  &  Display  components 


•  Common  middleware 
infrastructure 


•  e.g..  Real-time  CORBA 


&  Lightweight  CORBA 
Component  Model 
(CCM)  variant  called  Prism 


Bold  Stroke  Common  Components 

Domain-specific  Services  1  ~ 

X  Common  Middleware  Sen/ices  ]| 


Distribution  Middleware 
Host  I  nfrastructure  Middleware 


OS  &  Network  Protocols 
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Hm  Applying  SCV  to  the  Bold  Stroke  SPL 


Variabilities  6escv\be  the  attributes 
unique  to  the  different  nnembers  of 
the  family 

•  Product-dependent  component 
implementations  (GPS/INS) 

•  Product-dependent  component 
connections 

•  Product-dependent  component 
assemblies 

•  e.g.,  different  packages  for 
different  custonners  & 
countries 

•  Different  hardware,  OS,  & 
network/ bus  configurations 


Patterns  &  franneworks  are 
essential  for  developing 
reusable  SPLs 


F/A  18  F 
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Hardware  (CPU,  Memory,  I/O) 


m  Applying  Patterns  &  Frameworks  to  Bold  Stroke 
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Pattern- oriented  domain-specific  appiication 

framework 

•  Configurable  to  variable  infrastructure 
configurations 

•  Supports  systematic  reuse  of  mission 
computing  functionality 

•  3-5  million  lines  of  C-F- F,  C,  Ada,  &  Real¬ 
time  J  ava 

•  Based  on  many  architecture  &  design 
patterns 


Patterns  &  frameworks 
are  also  used  throughout 
Bold  Stroke  COTS 
software  infrastructure 
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Overview  of  Patterns 


•  Present  solutions  to 
comnnon  software 
problems  arisi  ng 
within  a  particular 
context 


•  Help  resolve 
key  software 
design  forces 


Flexibility 

Extensibility 

Dependability 

Predictability 

Scalability 

Efficiency 


•  Capture  recurring  structures  & 
dynamics  among  software 
participants  to  facilitate  reuse  of 
successful  designs 


•  Codify  expert  knowledge  of  design 
strategies,  constraints,  &  best  practices 


*J2EE  Patterns 


Best  Praclxcs  and  Ocsif*  Stnttfics 


Small  Memory 
Software 
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Overview  of  Pattern  Languages 


Motivation 

•  I  ndividual  patterns  &  pattern 
catalogs  are  insufficient 

•  Software  modeling  nnethods  & 
tools  largely  just  illustrate 
what/how-  not  why- 
systenns  are  designed 


PATTERN-ORIENTED 

SOFTWARE 

ARCHITECTURE 

I  Patlirn  Lingiigeftr 
DlElfllutad  ObliEl  Computing 


OPERATION  y  U _ 


ABSTRACT 

FACTORY 

THREAD- 

SPECIFIC 

STORAGE 


Benefits  of  Pattern  Languages 

•  Define  a  vocabu/ary^ov  talking  about  software 
development  problems 

•  Provide  a  process ^O'c  the  orderly  resolution  of 
these  problems 

•  Help  to  generate  &  reuse  software  architectures 
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Legacy  Avionics  Architectures 


Key  system  characteristics 

•  Hard  &  soft  real-time  deadlines 

•  -20-40  Hz 

•  Low  latency  &  jitter  between  boards 

•  —100  6>secs 

•  Periodic  &  aperiodic  processing 

•  Complex  dependencies 

•  Continuous  platform  upgrades 


Avionics  Mission 
Computing  Functions 

•  Weapons  targeting 
systems  (WTS) 

•  Airframe  &  navigation 
(Nav) 

•  Sensor  control  (GPS, 
IFF,  FUR) 

•  Heads-up  disSPLy 
(HUD) 


4:  Mission 
functions 
perform 
avionics 
operations 

3:  Sensor 
proxies 
process  data 
&  pass  to 
missions 
functions 
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Legacy  Avionics  Architectures 


Key  system  characteristics 

•  Hard  &  soft  real-time  deadlines 

•  -20-40  Hz 

•  Low  latency  &  jitter  between  boards 

•  —100  6>secs 

•  Periodic  &  aperiodic  processing 

•  Complex  dependencies 

•  Continuous  platform  upgrades 


AP 

GPS 


4:  Mission 
functions 
perform 
avionics 
operations 

3:  Sensor 
proxies 
process  data 
&  pass  to 
missions 
functions 


Limitations  with  legacy  avionics  architectures 

•  Stovepiped  •  Tightly  coupled 

•  Proprietary  •  Hard  to  schedule 

•  Expensive  •  Brittle  &  non-adaptive 

•  Vulnerable 


Cyclic  Exec 


2:  i/O  via 
interrupts 

1:  Sensors 
generate 
data 
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Decoupling  Avionics  Components 


Context 


•I/O  driven  DRE 
application 

•  Connplex 
dependencies 

•  Real-tinne  constraints 


structure 


Problenns  Solution 


•Tightly  coupled 
connponents 

•  Hard  to  schedule 

•  Expensive  to  evolve 


•Apply  the  Publisher-Subscriber 
architectural  pattern  to  distribute 
periodic,  I/O-driven 
data  fronn  a  single  point 
source  to  a  collection 
consunners 


Dynamics 
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Applying  Publisher- Subscriber  to  Bold  Stroke 


Bold  Stroke  uses  the  PubHsher- 

pattern  to  decouple  sensor 
processing  from  mission  computing 
operations 

•  Anonymous  publisher  &  subscriber 
relationships 

•  Group  communication 

•  Asynchrony 

Implementing  Publisher-Subscriber 
pattern  for  mission  computing: 

•  Event  notification  model 

•  Push  control  vs.  pull  data  interactions 

•  Scheduling  &  synchronization 
strategies 

•  e.g.,  priority- based  dispatching  & 
preemption 

•  Event  dependency  managennent 

•  e.g.,  filtering  &  correlation  mechanisms 
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Distributing  Avionics  Components 


Context 

Problems 

Solution 

•  Mission 
computing 
requires 
remote  1  PC 

•  Stringent  DRE 
requirements 

•Applications  need  capabilities  to: 
•Support  remote  communication 

•  Provide  location  transparency 

•  Handle  faults 

•  Manage  end-to-end  QoS 
•Encapsulate  low-level  system  details 

•Apply  the  Broker 
architectural  pattern  to 
provide  platform- neutral 
communication  between 
mission  computing 
boards 
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Distributing  Avionics  Components 


Context 

Problems 

Solution 

•  Mission 
computing 
requires 
remote  I  PC 

•  Stringent  DRE 
requirements 

•Applications  need  capabilities  to: 

•  Support  remote  communication 

•  Provide  location  transparency 

•  Handle  faults 

•  Manage  end-to-end  QoS 
•Encapsulate  low-level  system  details 

•Apply  the  Broker 
architectural  pattern  to 
provide  platform- neutral 
communication  between 
mission  computing 
boards 

Structure  &  Dynamics 
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Applying  the  Broker  Pattern  to  Bold  Stroke 


Bold  Stroke  uses  the  Broker 
pattern  to  shield  distributed 
applications  from  environment 
heterogeneity,  e.g., 

•  Programming  languages 

•  Operating  systems 

•  Networking  protocols 

•  Hardware 


A  key  consideration  for 
implementing  the  ^/r>/rar pattern  for 
mission  computing  applications  is 
QoS  support 

•  e.g.,  latency  jitter,  priority 
preservation,  dependability, 
security,  etc. 


pu^(  event 


Subscribers 


Nav 


Event 

Channel 


Publishers 
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6:  Subscribers 
perform 
avionics 
operations 

5:  Event  Channei 
pushes  events 
to 

subscribers(s) 

4:  Sensor 
pubiishers 
push  events 
to  event 
channei 

3:  Broker 
handies  i/O 
via  upcaiis 

2:  i/O  via 
interrupts 

1:  Sensors 
generate 
data 
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Key  Patterns  Used  to  Implement  Broker 
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Wrapper  facades  enhance 
portability 

Proxies  &  adapters  simplify 
client  &  server  applications, 
respectively 

Component  Configurator 
dynamically  configures  Factories 

Factories  produce  Strategies 

Strategies  implement 
interchangeable  policies 

Concurrency  strategies  use 
Reactor  Si  Leader/ Foiiowers 

Acceptor- Connector  decouples 
connection  management  from 
request  processing 

Managers  optimize  request 
demultiplexing 


WWW,  dre.  vanderbi  It.  edu/  —schmidt/  PDF/ORB-  patterns,  pdf 
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Enhancing  Broker  Flexibility  with  Strategy 


Context 

Problem 

Solution 

•  Multi-domain 

•  Flexible  Brokers  must  support  multiple 

•Apply  the  Strategy 

reusable 

policies  for  event  &  request  demuxing. 

to  factory  out  commonality 

middleware 

scheduling,  (de) marshaling,  connection 

amongst  variable  Broker 

Broker 

mgmt,  request  transfer,  &  concurrency 
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m  Consolidating  Strategies  with  Abstract  Factory 


Context 

Problem 

Solution 

•A  heavily 

•Aggressive  use  of  Strategy  pattern  creates 

•Apply  the  Abstract 

strategized 

a  configuration  nightmare 

Factory  pattern  to 

framework  or 

•Managing  many  individual  strategies  is 

consolidate  multiple 

application 

hard 

•  It’s  hard  to  ensure  that  groups  of 
semantically  compatible  strategies  are 
configured 

Broker  strategies  into 
semantically 
compatible 
configurations 
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Concrete  factories  create  groups  of  strategies 
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[HB  Configuring  Factories  w/  Component  Configurator 


Context 

Problem 

Solution 

•  Resource 

•  Prematurely  commit! ng  to  a  Broker 

•  Apply  the  Component 

constrained 

configuration  is  inflexible  &  inefficient 

Configurator  pattern 

systems 

•  Certain  decisions  cant  be  made  until 

to  assemble  the 

runtime 

desired  Broker  factories 

•  Users  forced  to  pay  for  components  they 

Sl  strategies  more 

dont  use 

effectively 

•  Broker  strategies  are 
decoupled  from  when 
the  strategy 
implementations  are 
configured  into 
Broker 

•  This  pattern  can 
reduce  the  memory 
footprint  of  Broker 
implementations 
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Benefits  of  Patterns 


Subscribers 
HUD 
push(  event) 

push(event) 

Publishers 


( - - ^ 

GPS 

^ _ > 

IFF 

c — ^ ^ 

FUR 

_ 

_ 

_ ^ 

Broker 


Mission  Computing  Services 
fi  Middleware  I  nfrastructiire 

I  I 


Operating  System 


Networking  I  nterfaces 


Hardware  (CPU,  Memory,  I/O) 


Enables  reuse  of  software 
architectures  &  (designs 

I  mproves  (developnnent  team 
communication 

Convey  “best  practices"  intuitively 

Transcen(ds  language-centric 
biases/ myopia 

Abstracts  away  from  many 
unimportant  (details 


_ 

www.(dre.van(derbilt.e(du/ 

~schmi(dt/  patterns,  html 
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Limitations  of  Patterns 


Subscribers 

push(  event) 
push(event) 

Publishers 


z _ 

k. 

/ 

k 

/■ 

Networking  I  nterfaces 

I  y  I  - 

Hardware  (CPU,  Memory,  I/O) 


Require  significant  teidious  & 
error- prone  human  effort  to 
hanidcraft  pattern 
i  mplementations 

Can  be  (deceptively  simple 

Leaves  many  important  (details 
unresolve(d,  particularly  for  DRE 
systems 


We  therefore  nee(d  more 
than  j  ust  patterns  to 
achieve  effective 
systematic  reuse 


www.(dre.van(derbilt.e(du/ 

~schmi(dt/  patterns,  html 
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Overview  of  Systematic  Reuse  Paradigms 


Class  Library  Architecture 

•  A  class  is  a  unit  of  abstraction  & 
implementation  in  an  OO  programming 
language,  i.e.,  a  reusable  lype that  often 
implements  patterns 

•  Classes  are  typically  passive 

Framework  Architecture 

•  A  framework \s  an  integrated  set  of 
classes  that  collaborate  to  produce  a 
reusable  architecture  for  a  family  of 
applications 

•  Frameworks  implement  pattern  languages 


Component/  Service- Oriented  Architecture 

•  A  component/service  is  an  encapsulation 
unit  with  one  or  more  interfaces  that 
provide  clients  with  access  to  its  services 

•  Components/ services  can  be  deployed  & 
configured  via  assemblies 
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Applying  Frameworks  to  Bold  Stroke 


Application- specific  functionality 


_ 

s. 

s. 

Operating  System 
Networking  I  nterfaces 

I  y  I 

Hardware  (CPU,  Memory,  I/O) 


Framework 

characteristics 


•  Frameworks  exhibit 
“inversion  of  control"  at 
runtinne  via  callbacks 

•  Franneworks  provi(de 
integratecd  (domain- 
specific  structures  & 
functionality 

•  Franneworks  are  "semi- 
complete"  applications 

www.(jre.van(jerbilt.e(du/ 

—schmicdt/franneworks.  html 
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Benefits  of  Frameworks 


•  Design  reuse 

•  e.g.,  by  implementing  patterns  that 
guide  application  developers 
through  the  steps  necessary  to 
ensure  successful  creation  & 
deployment  of  avionics  software 
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Benefits  of  Frameworks 
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•  Design  reuse 

•  e.g.,  by  implementing  patterns  that 
guide  application  developers 
through  the  steps  necessary  to 
ensure  successful  creation  & 
deployment  of  avionics  software 

•  I  mplementation  reuse 

•  e.g.,  by  amortizing  software 
lifecycle  costs  &  leveraging 
previous  development  & 
optimization  efforts 


package  org . apache . tomcat . session ; 

import  org . apache . tomcat . core . * ; 

import  org . apache . tomcat . util . StringManager ; 

import  j  ava .  io .  ; 

import  j  ava . net . * ; 

import  j  ava . util . * ; 

import  j  avax . servlet . * ; 

import  j  avax . servlet . http . * ; 

/** 

*  Core  implementation  of  a  server  session 

* 

*  ©author  James  Duncan  Davidson  [duncan@eng.sun.com] 

*  ©author  James  Todd  [gonzo@eng.sun.com] 

*/ 

public  class  ServerSession  { 

private  StringManager  sm  = 

StringManager . getManager ("org. apache . tomcat. session" ) ; 
private  Hashtable  values  =  new  Hashtable(); 
private  Hashtable  appSessions  =  new  Hashtable (); 
private  String  id; 

private  long  creationTime  =  System. currentTimeMillis (); ; 
private  long  thisAccessTime  =  creationTime; 
private  int  inactiveinterval  =  -1; 

ServerSession (String  id)  {  this. id  =  id;  } 

public  String  getld()  {  return  id;  } 

public  long  getCreationTime ( )  {  return  creationTime;  } 


public  ApplicationSession  getApplicationSession (Context  context, 
boolean  create)  { 

ApplicationSession  appSession  = 

(ApplicationSession) appSessions . get (context) ; 

if  (appSession  ==  null  &&  create)  { 

//  XXX 

//  sync  to  ensure  valid? 

appSession  =  new  ApplicationSession (id,  this,  context); 
appSessions .put (context,  appSession) ; 

} 

//  XXX 

//  make  sure  that  we  haven't  gone  over  the  end  of  our 
//  inactive  interval  --  if  so,  invalidate  &  create 
//  a  new  appSession 

return  appSession; 


void  removeApplicationSession (Context  context)  { 
appSessions . remove (context) ; 


} 


Benefits  of  Frameworks 


•  Design  reuse 

•  e.g.,  by  implementing  patterns  that 
guide  application  developers 
through  the  steps  necessary  to 
ensure  successful  creation  & 
deployment  of  avionics  software 

•  I  mplementation  reuse 

•  e.g.,  by  amortizing  software 
lifecycle  costs  &  leveraging 
previous  development  & 
optimization  efforts 

•  Validation  reuse 

•  e.g.,  by  amortizing  the  efforts  of 
validating  application-  &  platform- 
independent  portions  of  software, 
thereby  enhancing  software 
reliability  Sl  scalability 
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[Pebian  Nointerceptors 
IDebian  WChar  GCC  3.1 
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Build  Name 
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IConfigl  Compile 
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Limitations  of  Frameworks 


Frameworks  are  powerful,  but  hard  to 
develop  &  use  effectively 

Significant  time  required  to  evaluate 
applicability  &  quality  of  a  framework 
for  a  particular  domain 

Debugging  is  tricky  due  to  inversion  of 
control 

Verification  &  validation  is  tricky  due  to 
dynamic  binding 

May  incur  performance  overhead  due  to 
extra  (unnecessary)  levels  of  indirection 


/ 

- n - (\^  Sr  — (\ — - 

[  Mission  Computing  SeivicesJ 

/ / 

1  Middleware  1  nfrastructure  I 

/  - 1/ 

Operating  System  J  | 

/ 

Networking  1  nterfaces  J 

Hardware  (CPU,  Memory,  1/0)^ 

We  thus  need  something 
simpler  than  frameworks 
to  achieve  systematic 
reuse  for  DRE  systems 


WWW,  dre.  vanderbi  It.  edu/  —schmidt/  PDF/ Queue- 04.  pdf 
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The  Evolution  of  Middleware 


DRE  Applications 


Donnain-Specific 

Services 


Common 
Middleware  Services 


Distribution 

Middleware 


Host  I  nf restructure 
Middleware 


Operating  Systenns 
&  Protocols 


Hardware 


Historically,  mission- critical  DRE  apps  were  built 
directly  atop  hardware  &  OS 

•Tedious,  error- prone,  &  costly  over  lifecycles 

There  are  layers  of  middleware,  just  like 
there  are  layers  of  networking  protocols 

Standards- based  COTS  DRE  middleware  helps: 

•  Control  end-to-end  resources  &  QoS 

•  Leverage  hardware  &  software  technology 
advances 

•  Evolve  to  new  environnnents  &  requirennents 

•  Provide  a  wide  array  of  reusable,  off-the- 
shelf  developer-oriented  services 


Middleware  is  pervasive  in  enterprise  donnain 
&  is  becoming  pervasive  in  DRE  domain 
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Operating  System  &  Protocols 


•  Operating  systenns  &  protocols  provide  nnechanisms  to  manage  endsystem  resources. 


e.g., 

•  CPU  scheduling  &  dispatching 

•  Virtual  memory  management 

•  Secondary  storage,  persistence,  &  file  systenns 

•  Local  &  remote  interprocess  communication  (I  PC) 

•  OS  examples 

•  UNIX/ Linux,  Windows,  VxWorks,  QNX,  etc. 

•  Protocol  examples 

•  TCP,  UDP,  I P,  SCTR  RTP,  etc. 
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Host  Infrastructure  Middleware 


Host  infrastructure  nniddleware  encapsulates  &  enhances  native  OS 
mechanisnns  to  create  reusable  network  programming  objects 

•  These  components  abstract  away  many  tedious  &  error- prone 
aspects  of  low-level  OS  APIs 

Examples 

•  J  ava  Virtual  Machine  (JVM),  Comnnon  Language  Runtime 
(CLR),  ADAPTIVE  Communication  Environment  (ACE) 


Domai  n-  Specific 
Services 


Common 

Middleware  Services 


Distribution 

Middleware 
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Middleware 
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Distribution  Middleware 
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•  Distribution  middleware  6ef\nes  higher-level  distributed 
programming  models  whose  reusable  APIs  &  components 
automate  &  extend  native  OS  capabilities 

•  Examples 

•  OMG  Real-time  CORBA  &  DDS,  Sun  RMI,  Microsoft  DCOM, 
W3C  SOAP 


Domai  n-  Specific 
Services 


Common 

Middleware  Services 


Distribution 

Middleware 


Host  I  nfrastructure 
Middleware 


N1  App  1 
Piib/Sub 


N2  App  2 
Subscribe 


K3  App  3 
Pub/Sub 

K6  App  7 
Pub/Sub 


K4  App  4 
Piib/Sub 

N4  App  5 
Publish 


K5  App  6 
Subscribe 


N7  App  8 
Pub/Sub 


en .  wi  ki  ped  i  a .  org/  wi  ki/  Data_  Di  st  ri  but  i  on_  Service 


Distribution  middleware  avoids  hard-coding  client  &  server  application 
dependencies  on  object  location,  language,  OS,  protocols,  &  hardware 
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Common  Middleware  Services 


•  Comrmn  m/dd/eware  sen/Ices Bugrn&nit  Q}\stv\buX:\on  middleware 
by  defining  higher- level  domain- independent  services  that  focus 
on  programming  “business  logic" 

•  Examples 

•  W3C  Web  Services,  CORBA  Component  Model  &  Object  Services, 
Sun's  J2EE,  Microsoft's  .NET,  etc. 


Host  I  nfrastructure 
Middleware 
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•  Common  middleware  services 
support  many  recurring 
distributed  system  capabilities, 
e.g., 

•  Transactional  behavior 

•  Authentication  &  authorization, 

•  Database  connection  pooling  & 
concurrency  control 

•  Active  replication 

•  Dynamic  resource  management 
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Domain- Specific  Middleware 


Domain-specific  middieware  services  are  tailored  to  the 
requirements  of  particular  domains,  such  as  telecom,  e-commerce, 
health  care,  process  automation,  or  aerospace 


Domain-Specific 

Services 


Common 
Middleware  Services 


Distribution 

Middleware 


Examples 
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Siemens  MED  Syngo 

•  Common  software  platform  for 
distributed  electronic  medical  systems 

•  Used  by  all  Siemens  MED  business 


Host  I  nfrastructure 
Middleware 
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Boeing  Bold  Stroke 
•  Common  software 
platform  for  Boeing 
avionics  mission 
computing  systems 


Modalities 

e.g.,  MRI ,  CT,  CR, 
Ultrasound,  etc. 
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m  Applying  Component  Middleware  to  Bold  Stroke 
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Instrument  Cluster 
1 


Product- line  component  model 

•  Configurable  for  product- specific  functionality 
&  execution  environment 

•  Single  component  development  policies 

•  Standard  component  packaging  mechanisms 

•  3,000-1-  software  components 
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Benefits  of  Component  Middleware 


Creates  a  standard  “virtual 
boundary"  around 
application  component 
implementations  that 


Define  standard 
container  mechanisms 
needed  to  execute 
components  in  generic 


Specify  the  infrastructure 
needed  to  configure  & 
deploy  components  thruout 
a  distributed  system 
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Limitations  of  Component  Middleware 
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Limitations  of  Component  Middleware 


Load  Balancer 
FT  CORBA 

RT  CORBA  +  DRTSJ 

RTOS  +  RT 
Java 

I  ntServ  + 
Diffserv 


Workload  & 
Replicas 


Connections  & 
priority  bands 

CPU  &  memory 


Network  latency 
&  bandwidth  . 


•  Limit  to  how  much  application 
functionality  can  be  refactored  into 
reusable  COTS  component  middleware 

•  Middleware  itself  has  become  hard  to 
provision/ use 
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Limitations  of  Component  Middleware 


•  Limit  to  how  much  application 
functionality  can  be  refactored  into 
reusable  COTS  component  middleware 

•  Middleware  itself  has  become  hard  to 
provision/ use 

•  Large  #  of  components  can  be  tedious  & 
error- prone  to  configure  &  deploy  without 
proper  integration  tool  support 
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Limitations  of  Component  Middleware 
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RT-CORBA 
_ Apps _ 

J2ME 

_ Apre _ 

DDS 

Apps 

RT-CORBA 

Services 

J2ME 

Services 

DDS 

Services 

RT-CORBA 

J2ME 

DDS 

Operating  System 
&  Protocols 


Hardware  & 
Networks 


•  Limit  to  how  much  application 
functionality  can  be  refactored  into 
reusable  COTS  component  middleware 

•  Middleware  itself  has  become  hard  to 
provision/ use 

•  Large  #  of  components  can  be  tedious  & 
error- prone  to  configure  &  deploy  without 
proper  integration  tool  support 

There  are  many  middleware  technologies 

to  choose  from 
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Applying  MDE  to  Bold  Stroke 


Model-driven  engineering 
(MDE) 

•Apply  MDE  tools  to 

•  Model 

•  Analyze 

•  Synthesize 

•  Provision 

middleware  &  application 

components 

•  Configure  product  variant- 
specific  component  assembly 
&  deployment  environments 

•  Model- based  component 
integration  policies 


www.isis.vanderbilt.edu/ 

projects/ mobies 


V 


IQB 


Applying  MDE  to  Bold  Stroke 


UMiyRose 


ESMLV  GME 
PICMLV  GME 


EMBEDDED  PLATFORM  MODEL 
Avionics  Mission  Controi  Architecture 

#1  Avionics  Mission  Computer  #2  Avionics  Mission  Computer 

ili- 


APPUCADON  MODEUNG 
TOOLS 


Formal  mission  specs, 
subsystem  models,  & 
computational  constraints 
combined  into  integrated 
MDE  tool  chain  &  mapped 
to  execution  platforms 


ARI ES 
TimeWeaver 
TimeWiz 
Cadena 


PowerPC 

ACE+TAO 

Bold 

Stroke 


I  nteraction  is 
based  on  mission- 
specific  ontologies 
&  semantics 


Stateflow 

Statecharts 
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Simulink 

XML 
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Hardware  (CPU,  Memory,  I/O) 
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Benefits  of  MDE 


Avionics  Mission  Computing 
Modeiing  Languages 


I  ncrease  expressivity 

•  e.g.,  linguistic  support  to  better 
capture  design  intent 

I  ncrease  precision 

•  e.g.,  mathematical  tools  for  cross¬ 
domain  modeling,  synchronizing 
models,  change  propagation  across 
models,  modeling  security  &  other 
QoS  aspects 

Achieve  reuse  of  domain  semantics 

•  Generate  code  that's  more  “platform- 
independent"  (or  not)! 

•  Support  DRE  system 
development  &  evolution 
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Limitations  of  MDE 


Applications. 


M(Klel  &  Component 
Library 


Modeling  technologies  are 
sti  1 1  matu  ri  ng  &  evol  vi  ng 

•  i.e.,  non-standard 
tools 

Magic  (&  magicians)  are 
still  necessary  for  success 
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I  ngredients  for  Success  with  Systematic  Reuse 


Key  Technologies 

Standard 
Middleware, 
Frameworks,  & 
Components 


NETWORK 


Experienced  Senior  Architects 

•  Responsible  for  communicating 
completeness,  correctness,  & 
consistency  of  all  parts  of  the 
software  architecture  to  the 
stakeholders 


Patterns  & 
Pattern 
Languages 


Model-driven 

Software 

Development 


o- 


■o 


REMOTE 

OPERATION 


ACTIVE 

OBJECT 

0— 

EVICT  OR 

Solid  Key  Developers 

•  Design  responsibility 
(maintenance,  evolution)  for  a 
specific  architectural  topic 

Enlightened  Managers 

•  Must  be  willing  to  defend  the 
sacrifice  of  some  short-term 
investment  for  long-term  payoff 

Accepted  Business  Drivers 

•  i.e.,  need  a  “succeed  or  die" 
mentality 


It's  crucial  to  have  an  effective  process  for  growing  architects  &  key  developers 
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Traits  of  Dysfunctional  Software  Organizations 


Process  Traits 

•  Death  through  quality 

•  'Process  bureaucracy" 

•  Analysis  paralysis 

•  "Zero- lines  of  code  seduction" 

•  I  nfrastructure  churn 

•  e.  g.,  programming  to  low-level 
APIs 

Organizational  Traits 

•  Disrespect  for  quality  developers 

•  "Coders  vs.  developers" 

•  Top-heavy  bureaucracy 
Sociological  Traits 

•  The  "Not  I  nvented  Here"  syndrome 

•  Modern  method  madness 


www.dre.vanderbilt.edu/~schmidt/editorials.html 


HHfrraits  of  Highly  Successful  Software  Organizations 
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Strong  leadership  in  business  Sc  technology 

•  e.g.,  understand  the  role  of  software 
technology 

•  Dont  wait  for  '^silver  bullets'' 

Clear  architectural  vision 

•  e.g.,  know  when  to  buy  vs.  build 

•  Avoid  worship  of  specific  tools  Sc 
technologies 

Effective  use  of  prototypes  &  demos 

•  e.g.,  reduce  risk  &  get  user  feedback 
Commitment  to/from  skilled  developers 

•  e.g.,  know  how  to  motivate  software 
developers  &  recognize  the  value  of 
thoughtware 
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m  Consequences  of  COTS  &  IT  Commoditization 


Applications 


iJsiiig  autodetected  IRQ  (11)  to  inprowe  pertornance. 
ifcust  (PC/TCP  Class  1  packet  driver  -  DIX  Ethernet)  ini 
1  free  packets  of  length  160.  5  free  packets  of  length  1 
The  kernel  is  using  asynchronous  sends 
fhe  Resident  Module  occupies  0  bytes  of  conventional  ne 


Hardware 


•  More  emphasis  on  integration  rather  than 
programming 

•  I  ncreased  technology  convergence  & 
standardization 

•  Mass  market  economies  of  scale  for  technology 
Sl  personnel 

•  More  disruptive  technologies  &  global 
competition 

•  Lower  priced — but  often  lower  quality — 
hardware  &  software  components 

•  The  decline  of  internally  funded  RSiD 

•  Potential  for  complexity  cap  in  next-generation 
complex  systems 


Not  all  trends  bode 
well  for  long-term 
competitiveness  of 
traditional  leaders 


Ultimately,  competitiveness 
depends  on  success  of  long-term 
R&D  on  co/rp/eY distributed  real¬ 
time  &  embedded  (DRE)  systems 


Concluding  Rennarks 


The  growing  size  &  complexity  of  DRE 
systems  requires  significant  innovations 
&  advances  in  processes,  methods, 
platforms,  &  tools 

Not  all  technologies  provide  precision  of 
legacy  real-time  &  embedded  systems 

Advances  in  Model- Driven  Engineering 
Sl  component/ SOA- based  DRE  system 
middleware  are  needed  to  address 
future  challenges 

Significant  groundwork  laid  in  DARPA  & 
NSF  programs 


Much  more  R&D  needed  to  assure  key 
quality  attributes  of  DRE  systenns 


Ultra-Large-Scale 

Systems 

Th«  Software  Challenge 
of  the  Future 


See  blog.sei.cmu.edu  for  coverage  of  SEI  R&D  activities 
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Further  Reading 


ULS  systems  are  socio-technical  ecosystems 
comprised  of  software- reliant  systems,  people, 
policies,  cultures,  &  economics  that  have 
unprecedented  scale  in  the  following  dimensions: 

•  #  of  lines  of  software  code  &  hardware 
elements 

•  #  of  connections  &  interdependencies 

•  #  of  computational  elements 


•  #  of  purposes  &  user  perception  of  purposes 

•  #  of  routine  processes  &  “emergent 
behaviors" 

•  #  of  (overlapping)  policy  domains  & 
enforceable  mechanisms 

•  #  of  people  involved  in  some  way 

•  Amount  of  data  stored,  accessed,  & 
manipulated 

WWW.  sei .  cnnu .  ed  u/  u  I  s 

•  etc 

■  ■  ■  ■  ■  ■ 


See  blog.sei.cmu.edu  for  discussions  of  software  RStD  activities 
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Further  Reading 


NRC  Report  Critical  Code:  Software  Produdbiiity  for  Defense  (2010) 


Focus  of  the  report  is  on  ensuring  the  DoD 
has  the  technical  capacity  &  workforce  to 
design,  produce,  assure,  &  evolve  innovative 
software- reliant  systems  in  a  predictable 
manner,  while  effectively  managing  risk, 
cost,  schedule,  &  complexity 


Sponsored  by  Office  of  the  Secretary  of  Defense  (OSD) 
with  assistance  from  the  National  Science  Foundation 
(NSF),  &  Office  of  Naval  Research  (ONR), 

WWW. nap.edu/openbook.  php?record_id=12979&page=Rl 


See  blog.sei.cmu.edu  for  discussions  of  software  RStD  activities 


